Network Support Library/RoseWare - Network Support Library.iso/pressgen/ring0.txt

Text File | 1990-02-21 | 8KB | 130 lines

Ring 0, a Developer's view

     Largely discussed in recent trade magazines (PC Week, 2/12/90) is
the folly of Novell's choice to use Ring 0 memory protection, also
known as Privilege Level 0.  In all honesty it is possible to create an
application which will "crash" any file server, NetWare not
withstanding.  But the term "crash" is loosely defined.  Throughout the
NetWare commentaries I've viewed, it is presumed that NetWare 386 is
the first NetWare version designed to run all applications at ring 0.
Rather, the first to run server-based applications at ring 0  was
NetWare 286 v2.1, first delivered in 1987.  These applications were
called VAPs (Value Added Processes,  NetWare 386 terms such
applications NLMs or NetWare Loadable Modules).  If one were to analyze
what VAPs (though, commercially they number fewer than a 100) have done
in the way of crashing NetWare 286 servers, then a taste of the future
might be at hand.  But, in your review, be sure to realize the relative
difficulty of creating a VAP versus creating an NLM.

     What does ring 0 protection actually provide?  In all honesty, not
much.  Let's take a big for instance, DOS applications all run at ring
0.  Further, just how many DOS applications have you encountered that
actually violated memory of other applications?  Other applications
include DOS itself, device drivers, TSRs and other DOS programs.
Recognizing that developing a NetWare 386 NLM is much like that of
creating a DOS application (minus the ability to multithread the code)
one would then understand that avoiding the coding of an ill-behaved
(i.e. a program that writes over areas of memory which do not belong to
it) application is not that difficult.  It is understood that an
ill-behaved NLM could cause more chaos that an ill-behaved DOS
application, but not necessarily.  We have already been witness to what
damage viruses from the DOS world can do to files on a LAN.  The worst
that an ill-behaved NLM could do is erase your network volumes.  This
worry is much negated by a consistent and implemented backup strategy.

     But let's face facts.  We developers are not creating applications
that will destroy or damage your system.  With the current concern over
memory protection issues we will, more than likely, be utterly careful
in the coding of our NLMs.  After all, we make our living from their
success.  And with coding differences between NLMs and DOS applications
being relatively small, those successful at creating DOS applications
should be able to do the same with NLMs.

     I'd like to point out another fact in the ring x memory protection
concern.  Surprise, OS/2 itself is not completely safe.  Device drivers
written for OS/2 run at ring 2 and applications at ring 3.  This means
that a carelessly written device driver, perhaps for a disk drive, can
overwrite an application's memory thus reducing or eliminating its
usefulness.  Let me point out that there are 4 rings of protection for
the current line of Intel 80x86 CPUs.  These rings number 0 through 3.
Essentially, an application has access rights to memory at its ring
level and those levels beneath it.  For instance, ring 3 is beneath
ring 2, which is below ring 1 which is below ring 0.

     I would like to offer  a concern that is more likely to be an
issue, once server-based applications begin to show up in bulk. That
issue is that of CPU scheduling.  OS/2 operates with the default that
an application does not schedule itself and thus does not have control
over when it will execute.  This can create programming problems that
must be endured by the application developer.  Since they have no
control of when their application will be running, they can not make
simple assumptions that would be possible otherwise.  Assumptions such
as timeliness of execution, current state of memory and its values, and
other caveats that would be more the domain of a programmer's journal
than this periodical.  However, under OS/2, because of its preemptive
scheduling (i.e. applications do not schedule themselves), all
applications are guaranteed CPU time and thus an equal chance to
execute.  With NetWare 386 (as well as 286), scheduling is
non-preemptive, i.e. each application is free to run till completion or
it may schedule its own preemption.  Because of this, it is possible
for a NetWare 386 server-based applications to run through long
sections without giving up the CPU.  The application might give up
control of the CPU in order to allow execute-time for other
applications, including the server operating system itself.  By
following a few fundamental rules, NLMs can be designed and coded to
allow for appropriate preemptive breaks without disturbing its own
execution or delaying that of others.  In fact, Novell may, if not
already, implement such preemptive breaks each time a library routine
is called.  Under NetWare 386 (unlike NetWare 286), NLMs all call the
same set of Novell supplied library routines.  It is these routines
where Novell may decide to implement breaks such that performance of a
current application is not adversely affected and other applications
are given CPU time.  Consequently, NetWare 286's VAPs would not benefit
from such changes, primarily due to the lack of a common set of library
routines.

     As noted above, the question of performance not memory protection
should be the focus of your commentators.  It is true that OS/2 with is
general purpose operating system design, will, given the same
conditions run slower than a LAN OS designed to meet the high
performance needs of a LAN environment.  However, in a non-preemptive
OS such as NetWare 386, there exists the ability for an NLM to run
"till completion" without giving up the CPU for other applications to
execute.  But, with the implementation of a few basic rules governing
program execution, any undue performance penalty an NLM could introduce
can be circumvented.  With OS/2 the performance penalty remains and is
not under the control of a developer.  Some could retort by saying an
NLM developer wishing to get the most performance from their NLM may
resort to CPU dominance, rather than following guidelines for
preemptive programming.  In reply, there are three strategies, one,
users themselves may note a marked decrease in system performance upon
the use of such an NLM.  And, noting such a decrease, will likely call
the vendor to find out what is going on, if indeed this is a concern,
request appropriate changes be made.  Second, as noted earlier, Novell
may decide to code preemptive breaks in their library routines.  Please
note the fact that an NLM will not have much work to perform if it is
not, somehow, using these library routines, hence the effectiveness of
placing preemption techniques in the library routines.  However, it is
possible for an NLM to "sit and wait", thus, consuming CPU time without
doing any library calls, so the insertion of preemption routines in the
library can not be 100% effective.   Third, such a situation (where an
NLM controls CPU time for an extended amount of time) can be detected
and Novell may opt to include routines to detect such occurrences.
Processes that incur a large amount of contiguous CPU time could be
noted and, at the discretion of the LAN administrator, may be removed
from the system.

     In retrospect, I have been developing NLMs since June of 1989 and
have not run into trouble of my NLM overwriting memory outside its
definition, likewise, this is true of the VAPs I have written, which
date back to 1988.  However, I have had performance handicaps incurred
due to the lack of my NLM (or VAP) sufficiently preempting itself.
Thus the foundation for my lack of concern for "ring 0" protection.

John T. McCann
Systems R&D
Brightwork Development

I can be reached through CompuServe @ 70007,3430 or on the Internet
at [e-mail]